“Real-time” communication between users over a network (meaning communication exchanged between networked users with negligible latency) has recently become a ubiquitous form of communication. Such real-time communication includes audio/video conferencing, Voice over Internet Protocol (VoIP), or instant messaging, among others. Moreover, each of these forms of real-time communication are implemented using Session Initiation Protocol (SIP) as described, for example, in Request for Comments (RFC) 3261 published June 2002 by IETF (Internet Engineering Task Force) Network Working Group and any subsequent revisions, wherein SIP is used to initiate, modify, and terminate communication sessions between user agents. SIP and other related or similar session protocols used to initiate, modify, and terminate communication sessions between users is referred to herein, generally, as “session control protocols”.
A communication session or dialog within a session control protocol framework involving multiple users or “participants” is known as a “conference” or “conference call”. The session control protocol framework (also referred to herein as a conferencing network) comprises a central Focus server (or simply Focus server) and one or more mixer nodes. Operationally, the Focus server implements a conference policy and exchanges session control protocol (e.g., SIP) signaling with conference participants to establish, modify, and terminate one or more conferences; and each mixer node receives one or more media streams from the conference participants, combines the media streams, and redistributes the one or more media streams to the conference participants.
At times, in the case of one or more conferences with a very large number of participants, a single mixer node may not be able to handle the media load. Accordingly, a single mixer node is replaced by a plurality of mixer nodes configured in a cascaded mixer node architecture, with each mixer node referred to herein as a “cascaded mixer node”. In the case of a conferencing network with a cascaded mixer node architecture, to enhance system performance for conferences having a large number of participants and to balance media loads among all computational resources and communications pipelines in the system, the plurality of cascaded mixer nodes are distributed throughout a designated conferencing network, such as among others, a local area network (LAN) or a wide area network (WAN). In addition, for each active conference in the conferencing network, the cascaded mixer nodes are arranged in a tree topology with each mixer node in the tree topology connecting to at least one other mixer node and also connecting to the Focus server by a session control protocol dialog.
Current conferencing networks, that include a cascaded mixer node architecture, support a “fully-coupled model”; meaning that, not only does the Focus server implement the above-mentioned functionality of communication session control, the Focus server further establishes the mixer node tree topology per conference call and controls each mixer node's state within each conference tree as either a root node or a leaf node. In other words, in the “fully-coupled model”, the Focus server in connection with a conference policy server (which stores and controls conference policy) are in full control over the distributed cascaded mixer nodes to implement, among other functions, command on a per-call tree topology, handling load problems in the cascaded mixer node architecture, handling failure events of cascaded mixer nodes, etc. While it can exploit the benefits of the cascaded mixer node architecture, the fully-coupled model suffers from an increased computational load on the conference policy server and the Focus server, and it is tied to a specific conference policy server and Focus server; thus, a failure of the Focus server or an inability of the Focus server to access the conference policy server will effectively shut down all conferences in the network.
Accordingly, there is a need for a decoupled cascaded mixer node architecture and related methods.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments. In addition, the description and drawings do not necessarily require the order illustrated. It will be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required.
Apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.